Integration Guide KUKA KRC LS 1.5

This guide describes how to integrate KUKA KRC robots with Locator Studio (LS) 1.5.

1. Robot Controller Setup

Before you start, make sure that the robot controller meets these requirements:

KUKA KRC4 or KRC5 controller with KUKA System Software (KSS) 8.3 or higher
KUKA.EthernetKRL option, version 2.2.8 or higher. To check it, switch to Expert mode and open Menu -> Startup -> Additional software. If EthernetKRL is not installed, contact your local KUKA sales or support representative.

The Robot module support matrix lists the supported versions of all Robot modules.

1.1 Initial Setup and Configuration

The KRC controller has several Ethernet ports, and each port has a specific purpose. To communicate with external devices such as a PC or a vision controller, use the KUKA Line Interface (KLI).

The exact layout can be slightly different between KRC4 models (for example, compact and standard). However, the KLI port is almost always accessible from the outside. On our controller, the KLI port is on the rear side of the KRC4 cabinet door, as shown in the figures below. From there, it is usually routed either to the main connection panel at the bottom of the controller or to outlets on the upper cabinet door. Follow the cable to see where it leads, and plug your Ethernet cable into the matching outlet. In some configurations, the LAN port of the internal motherboard is routed to the external X66 connector.

Connect the KLI port either directly to the Robot port of the vision controller or, for more complex networks, through a network switch.

The next step is the network configuration of the KUKA robot controller.

1.2 Network Configuration

The Photoneo KUKA module uses TCP/IP communication to transfer data between the KRC robot controller and LS.

As the first step of commissioning, make sure that the IP address of the KRC controller matches your network configuration.

Switch to Expert mode (use the KUKA Expert or Administrator login). Open the main menu and select Startup -> Network Configuration:

Select Fixed IP Address as the network method. Enter the IP address and subnet mask of the robot controller. This guide uses 192.168.1.2 and 255.255.255.0.

Click the Save button to confirm the changes. Reboot the KRC control PC to apply the new network configuration.

Open the Menu Screen and select Shutdown -> Reboot control PC:

Note

The subnet mask 255.255.255.0 is the same as a 24-bit subnet mask. For more combinations, see this table: https://dnsmadeeasy.com/support/subnet

Example of a matching network configuration on the vision controller side:

Vision controller IPv4 address: 192.168.1.1 / 24
Robot controller IPv4 address: 192.168.1.2 / 24 (as configured in the previous step)

You can also use the Test Connection button on the Network page of the vision controller to ping the KUKA robot controller.

Depending on the result of the test (ping command), a Robot Available or Robot Unavailable message pops up. If the robot is unavailable, check the cabling and the network configuration again.

1.3 Importing Photoneo KUKA module

The Photoneo LS KUKA module version 1.5 contains these files:

Ethernet KRL XML files (folder EthernetKRL, copy to C:\KRC\Roboter\Config\User\Common\EthernetKRL):

pho_loc_client.xml

Photoneo System files (folder Photoneo, copy to KRC:\R1\PHOTONEO):

pho_common.src
pho_common.dat

Example programs (folder Program, copy to KRC:\R1\Program; each .src comes with its .dat file):

basic_application.src
calibration.src
calibration_hand_eye.src
change_bbox.src
change_solution.src
comm_check.src
CollDetect_UserAction.src
get_status.src
hand_eye.src
meshing.src
multi_vision_system.src
reuse_scan.src

There are three ways to transfer the Photoneo KUKA module to the robot controller:

Copy the KOP (KUKA Option Package) from a USB flash drive - best for a quick first installation of the whole module.
Copy individual files from a USB flash drive - best when you need to work with individual files, for example to update the module version without losing your working programs.
Use WorkVisual - the most advanced option, for KUKA professionals.

1.3.1 Using the KUKA Option Package

KUKA Option Packages are software add-ons. They add functions and simplify integration in the KUKA robotics ecosystem. For the Photoneo KUKA interface, the KOP installs all module files at once and copies them automatically to the correct locations, including the EthernetKRL XML file.

The easiest way to install the Photoneo KUKA module is to copy the Photoneo KUKA Option Package from a USB flash drive to the KUKA KRC controller and install it there.

By default, Photoneo_LS_1_5_0.kop is not in the list. To add it, click the New Software button at the bottom, as shown below. The InstallTech selection window opens, and Photoneo_LS_1_5_0.kop should be in the list. Select the check box on the left and click Install.

Photoneo_LS_1_5_0.kop is installed on the robot controller. A message shows the number of files that are added to the system. Confirm with “Yes” to finish the installation.

After the KOP is installed, the Photoneo files are in the R1 folder. The PHOTONEO folder contains the system files, and the example programs are added to the Program folder:

The EthernetKRL XML file is also added to C:\KRC\Roboter\Config\User\Common\EthernetKRL.

1.3.2 Using a USB Flash Drive

You can also copy the files to the KUKA KRC controller directly from a USB flash drive with the Edit and Copy buttons. Use this method when you need to work with individual files. For example, a module update usually replaces only pho_common.src and pho_common.dat, and the KOP might break existing programs.

When you copy files individually, keep the folder structure shown in the picture above. The location of the EthernetKRL file is critical and must match the requirements.

1.3.3 Using WorkVisual

For the most convenient work with the Photoneo KUKA interface, we recommend a remote connection from a PC to the robot controller with KUKA WorkVisual. You can download KUKA WorkVisual free of charge from the official KUKA website.

To connect the PC, use an Ethernet switch to split the KLI connection of the robot, or use the robot service Ethernet port X43 or X66. Make sure that your PC is in the same subnet as the robot controller interface. Then start KUKA WorkVisual on your PC.

In KUKA WorkVisual, go to Programming and diagnosis in the workspace selection. Then click the Create connection button to connect to the real robot controller.

A window opens. If the robot is reachable on the network, it is shown in the list, as below. Click OK to connect and download the current file structure from the robot to WorkVisual:

After you connect, right-click the robot name and select Open in Windows Explorer to open the folder with the project files. This is usually C:\Users\your_username\Documents\WorkVisual 6.0\Repositories\Robot_Name\KRC:

Use File Explorer, Total Commander or another tool to copy the Photoneo files directly into this project folder. When you are ready, right-click the robot name and select Transfer Changes to transfer the files to the robot controller. A list of all changed files is shown. Click OK to start the transfer.

To transfer the EthernetKRL file, copy the XML file to the Photoneo folder in WorkVisual. Then copy it manually to C:\KRC\Roboter\Config\User\Common\EthernetKRL with the Edit and Copy buttons on the teach pendant. Alternatively, change the robot configuration directly in the Configuration and Commissioning workspace of WorkVisual.

1.4 Ethernet KRL configuration

The EthernetKRL folder contains one XML file, pho_loc_client.xml. Copy this file to C:\KRC\Roboter\Config\User\Common\EthernetKRL.

The XML file contains the configuration of the EKI communication interface. The only entry that you need to change is the IP address.

Enter the IP address of the vision controller in the External IP tag in pho_loc_client.xml, as shown in the figure below. Do not change the default port 54601 for pho_loc_client.

Save the changes and reboot the control PC again to apply the new EthernetKRL configuration.

The file also sets the EthernetKRL flags that the module uses: $FLAG[101] is TRUE while the connection is open, and $FLAG[102] is TRUE when received data is waiting in the buffer. Do not use these two flags anywhere else in your robot programs.

Vision controller side: By default, the Action Request Server of LS listens on port 11003, but the Robot module connects to port 54601. On the Network page of LS, enter 54601 in the Action Request Server port (ARS port) field. For details, see Network setup.

1.5 Tool TCP Setup

The tool setup is more important for LS than for Bin Picking Studio (BPS). BPS works with a zeroed tool and compensates for the tool offset in software. The general rule for LS: do all scanning and calibration in the $NULLFRAME frame, and do all picking with the real tool. This guide uses a tool named “CustomTool” with the offset Z = 205 mm.

Change the TCP whenever the robot must use a specific tool frame. For example, scan and calibration requests always need “$NULLFRAME”, but picking based on the result of Get Poses needs “1 Custom Tool”.

1.6 Using the Photoneo KUKA Module

The Photoneo KUKA interface consists of ‘user frontend’ programs and ‘communication backend’ programs. pho_common.src and pho_common.dat are the communication backend. The example programs in the Program folder are designed so that you can deploy them quickly and change them easily.

basic_application.src is a very simple example of a Cartesian picking sequence. It shows the essential workflow: connect to LS, trigger a scan, request object poses (Get Poses), and execute the pick-and-place operation. The other example programs (multi_vision_system.src, change_solution.src, change_bbox.src, get_status.src, reuse_scan.src, …) are built on basic_application.src and add extra request calls to show various features.

If you followed the steps in section 1.3.3, you already have a WorkVisual connection and the project is deployed on your controller. Open basic_application.src to review the code. If your solution on the vision controller is ready, you only need to touch up the Home, Start and End poses and the placing poses P1, P2 and P3. The program is then ready to run. The Runtime section gives all the details for the final changes.

Important

The example programs work immediately, but the feature that you want to use must already be set up and active in LS. For example, to test the Change Bounding Box function, configure at least 2 bounding boxes in your solution.

2. Robot Module

Note

We strongly recommend that you read the Robot communication overview and the Action requests page before this section.

2.1 Connection to Photoneo Vision Controller

Note

The PHO_ConnectToVc() function connects to the Action Request Server on the vision controller at the start of the program.

The PHO_ConnectToVc() procedure opens the Ethernet KRL channel pho_loc_client, which is configured in pho_loc_client.xml (see section 1.4). Therefore, you do not need to set an IP address or port in the program. The procedure waits until the connection is open ($FLAG[101]), sends the brand ID string (see section 4) and resets the request tracking. If $FLAG[101] is already TRUE, the procedure returns immediately.

PHO_DisconnectFromVc() closes and clears the Ethernet KRL channel and resets $FLAG[101] and $FLAG[102].

You can send requests to the vision controller only after the connection is established. When the program on the KUKA side starts and connects, green Connected indicators are shown on the Deployment page (see the image below).

2.2 Request List

This section describes the API calls of the Robot module. Use these procedures for high-level control of the locator application. All of them are declared GLOBAL in pho_common.src, so you can call them from any robot program. For the meaning of each request, see Action requests.

Note

These procedures are defined in the communication backend. Do not edit them.

Values marked (global) in the Input column are global variables from pho_common.dat. Set them before the call. All other inputs are call parameters. Every request (except PHO_RequestScan, see below) waits for the response and returns the error code. The same value is also stored in the global variable error_code.

Request	ID	Definition	Input	Populates
Calibration Start	25	`PHO_RequestCalibStart(arg_solution_id, arg_vision_system_id)`	`arg_solution_id`, `arg_vision_system_id`	error_code
Calibration Add Point	5	`PHO_RequestCalibAdd()`	Current tool pose (`$POS_ACT_MES`), read automatically	error_code
Calibration Save	27	`PHO_RequestCalibSave()`	None	error_code, calib_error_um, calib_pose
Calibration Stop	26	`PHO_RequestCalibStop()`	None	error_code
Scan	19	`PHO_RequestScan()`	vision_system_id (global); current tool pose if `HAND_EYE_ENABLED` = TRUE	error_code (returned by `PHO_WaitForScan()`)
Capture (Dynamic Meshing)	30	`PHO_RequestCapture()`	vision_system_id (global), current tool pose (requires `HAND_EYE_ENABLED` = TRUE)	error_code
Reuse Scan	31	`PHO_ReuseScan()`	vision_system_id (global); current tool pose if `HAND_EYE_ENABLED` = TRUE	error_code
Get Poses	20	`PHO_RequestGetPoses(num_of_req_targets)`	vision_system_id (global), `num_of_req_targets`	error_code, object_poses, num_of_objects_received, dimension_x, dimension_y, rot_z_angle_deg, nn_label, max_z_height, tilt_angle_deg
Get Vision System Status	22	`PHO_RequestGetStatus()`	vision_system_id (global)	error_code, num_of_localized_objects, num_of_ready_objects, vs_still_processing
Change Bounding Box	33	`PHO_RequestChangeBBox(bbox_id)`	vision_system_id (global), `bbox_id`	error_code
Change Solution	9	`PHO_RequestChangeSol(solution_id)`	`solution_id`	error_code (no return value, read `error_code`)
Start Solution	10	`PHO_RequestStartSol(solution_id)`	`solution_id`	error_code
Stop Solution	11	`PHO_RequestStopSol()`	None	error_code
Get Running Solution	12	`PHO_RequestGetRunningSol()`	None	error_code, running_sol_id
Communication Check	100	`PHO_RequestCommCheck()`	None	error_code

Scan and tool pose: If HAND_EYE_ENABLED is FALSE, PHO_RequestScan() and PHO_ReuseScan() send only vision_system_id. If it is TRUE, they also send the current tool pose of the robot ($POS_ACT_MES), so the robot must stand still in the scanning pose. PHO_RequestCalibAdd() and PHO_RequestCapture() always send the current tool pose. A TOOL and BASE must be selected. Otherwise, the program stops with the message Tool/Base Frame not selected!.

Scan is split into two calls: PHO_RequestScan() only sends the request and returns immediately. With a hand-eye sensor, keep the robot still until the scan response arrives. With an extrinsic sensor, the robot can move in the meantime if it stays out of the scanned scene. The only exception is dynamic MultiView, where the sensor scans while the robot moves. PHO_WaitForScan() waits for the scan response and returns the error code. Call PHO_WaitForScan() exactly once after every PHO_RequestScan(). PHO_ReuseScan() waits for its own response.

2.3 Auxiliary Procedures

Procedure	Description
`PHO_ConnectToVc()`	Opens the Ethernet KRL connection and sends the brand ID (see section 2.1).
`PHO_DisconnectFromVc()`	Closes the Ethernet KRL connection (see section 2.1).
`PHO_WaitForScan()`	Waits for the response to `PHO_RequestScan()` and returns the error code.
`PHO_ReportError(code, isQuit)`	Shows a readable message for an error code on the smartHMI. `isQuit` = TRUE shows an acknowledgement message (`msgQuit`), and FALSE shows a notification (`msgNotify`).
`PHO_NotifyErrCode(code)` / `PHO_QuitErrCode(code)`	Shortcuts for `PHO_ReportError(code, FALSE)` / `PHO_ReportError(code, TRUE)`. Every request calls `PHO_NotifyErrCode()` automatically when the error code is not 0.

2.4 Info Data

Additional values sent with the responses (Info data) are stored in global variables in pho_common.dat. The module converts angles from milliradians to degrees.

Info data key	Variable	Type	Unit in robot	Sent by
4 - Dimension X	`dimension_x`	INT	mm	Get Poses
5 - Dimension Y	`dimension_y`	INT	mm	Get Poses
6 - Rotation Z	`rot_z_angle_deg`	REAL	deg	Get Poses
7 - Neural network label	`nn_label`	INT	integer	Get Poses
8 - Max Z height	`max_z_height`	INT	mm	Get Poses
9 - Tilt	`tilt_angle_deg`	REAL	deg	Get Poses
10 - Calibration accuracy	`calib_error_um`	REAL	µm	Calibration Save
11 - Running solution ID	`running_sol_id`	INT	integer	Get Running Solution
12 - Number of localized objects	`num_of_localized_objects`	INT	integer	Get Vision System Status
13 - Number of ready objects	`num_of_ready_objects`	INT	integer	Get Vision System Status
14 - Processing state	`vs_still_processing`	INT	0 / 1	Get Vision System Status

The variables keep their last value until a new value is received. Read them only when the request returned 0 (PHO_OK).

2.5 Variables and Flags

Global variables and flags used by the module (declared in pho_common.dat unless noted otherwise):

Name	Type	Description
`vision_system_id`	INT	ID of the vision system used by Scan, Capture, Reuse Scan, Get Poses, Get Vision System Status and Change Bounding Box. Set it before the call.
`HAND_EYE_ENABLED`	BOOL	TRUE for a robot-mounted (hand-eye) scanner: the scan requests send the current tool pose. Default FALSE.
`PHO_DEBUG`	BOOL	TRUE shows a smartHMI message for every sent request and every received response. Default FALSE.
`object_poses[100]`	POS	Object poses received by Get Poses (X, Y, Z in mm, A, B, C in deg). Up to 100 poses are stored.
`num_of_objects_received`	INT	Number of poses received by the last Get Poses request.
`calib_pose`	POS	Calibration result received by Calibration Save.
`error_code`	INT	Error code of the last request (0 = OK).
`$FLAG[101]`	Flag	Set by EthernetKRL while the connection to the vision controller is open (`ALIVE` flag in pho_loc_client.xml).
`$FLAG[102]`	Flag	Set by EthernetKRL when received data is waiting in the buffer (pho_loc_client.xml).

2.6 Error Codes

Error codes are defined as global constants in pho_common.dat. Their meaning and troubleshooting are described on the Error codes page. Codes that are not in this list are reported by PHO_ReportError() with their number.

Constant	Value	Meaning
`PHO_OK`	0	No error
`PHO_SERVICE_ERR`	1	Service error
`PHO_UNKNOWN_REQ`	2	Unknown request
`PHO_COMM_FAILURE`	3	Communication failure (connection lost)
`PHO_BAD_DATA`	4	Bad data (unexpected response)
`PHO_TIMEOUT`	5	Timeout
`PHO_UNKNOWN_ERR`	200	Unknown error; also set by the module when the request / response order is broken
`PHO_INVALID_SOL`	450	Invalid solution ID
`PHO_ANOTHER_SOL`	451	Another solution is running
`PHO_SOL_START_ER`	452	Deployment not started
`PHO_SOL_NOT_RUN`	453	Deployment is not running
`PHO_SOL_STOP_ERR`	454	Deployment did not stop
`PHO_SOL_INCOMPL`	455	Solution is not complete
`PHO_INVAL_BRAND`	457	Invalid robot brand
`PHO_SOL_RUNNING`	458	Solution already running
`PHO_SOL_FORBID`	459	Solution access unauthorized
`PHO_INVALID_VS`	460	Invalid vision system
`PHO_CALIB_RUNN`	461	Calibration is already running
`PHO_CALIB_N_RUNN`	462	Calibration is not running
`PHO_CALIB_STOP_E`	463	Calibration could not be stopped
`PHO_CALIB_STRT_E`	464	Calibration could not be started
`PHO_CALIB_DISABL`	465	Automatic calibration is disabled
`PHO_NOT_ENOUGH_P`	466	Not enough calibration points
`PHO_NOT_ENOUGH_A`	467	Calibration accuracy is above the allowed threshold
`PHO_SCANNER_NA`	468	Scanner not available
`PHO_CALIB_FORBID`	469	Calibration not allowed
`PHO_VS_NOT_FOUND`	500	Vision system not found
`PHO_EMPTY_SCENE`	501	Empty scene
`PHO_NO_PART_FOUND_RUN`	502	No object found, detection still running
`PHO_NO_PART_FOUND_STOP`	503	No object found, detection stopped
`PHO_PARTS_REJECTED_RUN`	504	All objects rejected, detection still running
`PHO_PARTS_REJECTED_STOP`	505	All objects rejected, detection stopped

2.7 Example Programs

The Photoneo KUKA module includes several example programs. They show how to use the requests listed in this section for various use cases:

Example program	Description
`basic_application.src`	This simple example shows the basic workflow: connect to the vision controller, trigger a scan request, wait for the scan to finish, request and receive object poses, and execute the picks. It also shows error handling for the `PHO_RequestGetPoses` status.
`hand_eye.src`	Same as basic_application, but configured for a hand-eye setup (`HAND_EYE_ENABLED` = TRUE). In this setup, the robot must move to a scanning pose before it triggers the scan request. The request then gives the vision controller the current pose of the camera.
`calibration.src` `calibration_hand_eye.src`	These examples show the calibration procedure for a static camera and for a robot-mounted camera. Things to know: Calibration steps: After you move the robot to each waypoint, call `PHO_RequestCalibAdd()` to add a calibration point. Automatic recalibration (optional): If `AUTO_CALIBRATION_ENABLED` is TRUE, the program runs the full recalibration cycle with `PHO_RequestCalibStart()`, `PHO_RequestCalibSave()` and `PHO_RequestCalibStop()`. Calibration accuracy: The calibration accuracy is stored in `calib_error_um`.
`multi_vision_system.src`	Same as basic_application, but switches between two vision systems. The program updates the `vision_system_id` variable before each scan or pose request. This variable selects which vision system is triggered or asked for data.
`change_solution.src`	Same as basic_application, but with solution switching. It shows how to use `PHO_RequestStopSol()` to stop a running solution, `PHO_RequestStartSol()` to start a new one, `PHO_RequestGetRunningSol()` to get the active solution ID, and `PHO_RequestChangeSol()` to switch solutions dynamically.
`change_bbox.src`	Same as basic_application, but with bounding box switching. It shows how to switch between bounding boxes dynamically with the `PHO_RequestChangeBBox(bbox_id)` request. Use it to change the localization search area without restarting the solution.
`get_status.src`	Same as basic_application, but with multiple Get Vision System Status requests. You can call `PHO_RequestGetStatus()` repeatedly at short intervals during localization. Returned values include: `num_of_localized_objects`: Number of localized objects `num_of_ready_objects`: Number of objects ready for picking `vs_still_processing`: Current state of the vision system These variables are often used for advanced decisions, especially to find the best time to start the pick procedure.
`meshing.src`	Dynamic meshing example. It combines Photoneo Instant Meshing technology with the Parallel Structured Light technique of MotionCam-3D. Dynamic meshing does not work with standard PhoXi 3D Scanners. Procedure Initial scan position: The robot position during the first scan is important for the correct orientation of the final point cloud. Therefore, the robot must not move until the first scan is received. Start capturing: Call `PHO_RequestCapture()` to start the capture procedure, so that MotionCam-3D starts meshing. Final scan: After the capture sequence, start the localization with a regular `PHO_RequestScan()`. This request does not perform an actual scan and does not emit light. It only starts the localization. Recommendations: Scanning trajectory and view: Make the scanning trajectory smooth, without sudden rotations. Keep the scanned area in the field of view to prevent tracking loss. Scan limit: To keep the best performance, do not use more than 60 scans in total.
`reuse_scan.src`	Same as basic_application, but alternates between two vision systems: vision system 1 performs a full scan, and vision system 2 localizes again on the same data with `PHO_ReuseScan()`, without a new scan. If the reuse scan fails, the program falls back to a new scan with vision system 1.
`comm_check.src`	Standalone communication test. It connects to the vision controller and calls `PHO_RequestCommCheck()` in a loop (10 checks, 2 s apart). On a failure, it resets `$FLAG[101]` and connects again. The robot moves only to the Home position.
`CollDetect_UserAction.src`	Empty KUKA collision detection user action routine. It is shipped so that the program set is complete. If needed, add your own reaction to a collision here.

2.8 Calibration

calibration.src (static scanner) and calibration_hand_eye.src (robot-mounted scanner, HAND_EYE_ENABLED = TRUE) move the robot through 9 calibration waypoints and call PHO_RequestCalibAdd() in each of them. The current tool pose is sent automatically, so a TOOL and BASE must be selected (use $NULLFRAME, see section 1.5).

Manual calibration (AUTO_CALIBRATION_ENABLED = FALSE, default): start the calibration on the Calibration page of LS, run the program to add the points, then save the result in the Studio.
Automatic calibration (AUTO_CALIBRATION_ENABLED = TRUE): the program does the whole cycle itself:
1. PHO_RequestStopSol() stops the running solution,
2. PHO_RequestCalibStart(solution_to_calibrate, vision_sys_to_calibrate) starts the calibration,
3. PHO_RequestCalibAdd() adds a point in each waypoint,
4. PHO_RequestCalibSave() computes and saves the result - the accuracy is stored in calib_error_um and the result in calib_pose,
5. PHO_RequestCalibStop() ends the calibration.
Set solution_to_calibrate and vision_sys_to_calibrate in the program before you run it. If the accuracy is above the allowed threshold, Calibration Save returns error 467.

3. Runtime

When the solution is fully configured on the vision controller, finish the remaining steps on the robot side and run the basic_application.src program.

3.1 Teach Positions

basic_application.src and the other example programs contain a few local poses (HOME, START). Touch them up before you run the program.

Select the basic_application.src program, click the SPTP Home line and click the Block Selection button in the bottom menu bar. Jog the robot to the new Home position and click the Touch Up button. For a static scanner, the Home position should be outside the scanning volume. Repeat these steps for the other local poses in the program.

Note

The approach and deapproach poses are calculated automatically. You only need to set the Z offsets in the code. The default example uses a Z offset of 200 mm for the approach and 300 mm for the deapproach.

3.2 Gripper commands

You must define the gripper commands yourself and use them to attach and release the parts at the correct moments.

3.3 Runtime Prerequisites

Do a final check before you run the LS KUKA interface from the robot side.

Make sure that:

the LS solution is correctly configured on the vision controller,
the network setup on the robot side is complete,
all vision systems defined in the solution are calibrated,
all local poses in the main program are touched up,
the gripper procedures are ready and working.

3.4 Running the basic_application.src Example Program

Deploy your solution. Until the communication is established, the Action Request Client (Robot) status on the Deployment page is DISCONNECTED.

Note

We strongly recommend that you reduce the override speed to 10% before you run the program for the first time.

If the connection is established correctly, the Action Request Client status changes to CONNECTED. The sensor then captures the first scan, and the localization of objects starts.

If there is a pickable object in the scene and the robot controller receives its Cartesian pose, the robot starts to move towards the first object.

If everything looks correct, keep moving the robot towards the first target and check that the path is correct. If the robot stops too far from the object, pushes the object too deep or approaches it with a wrong orientation, adjust the object origin in LS or the tool TCP on the robot side. You might need to calibrate the tool to get a correct pick.

If the robot movement looks correct, set up your own placing routine and slowly increase the speed up to 100%.

Congratulations, you have successfully deployed the Photoneo KUKA interface. You can now improve your application further. Use the cheat sheet and the example programs as your guidelines.

3.5 Communication Errors

If the connection to the vision controller is lost while the module waits for a response, the request returns 3 (PHO_COMM_FAILURE) and $FLAG[101] becomes FALSE. The example programs check $FLAG[101] at the start of each cycle and call PHO_ConnectToVc() again.
If a request cannot be sent or a received message cannot be read, the program stops with the message Error: COMM FAILURE.
The module allows only one request at a time. If a new request is sent before the previous response is received, or if a response does not match the request, the program stops with a Request response order is broken or Wrong Message type message and error_code is set to 200 (PHO_UNKNOWN_ERR) or 4 (PHO_BAD_DATA). Restart the program.
Every error code other than 0 returned by the vision controller is shown on the smartHMI by PHO_NotifyErrCode(). Set PHO_DEBUG = TRUE to see every request and response.
To test the connection without robot motion, run comm_check.src.

4. Version and Brand ID

This page describes the Photoneo KUKA KRC module 1.5.0 for Locator Studio 1.5. When the connection is opened, PHO_ConnectToVc() sends the brand ID string:

KUKA_KRC/L/1.5.0XXXedcba

KUKA_KRC is the robot brand, L stands for Locator Studio and 1.5.0 is the module version. The vision controller uses the brand ID to select the robot brand and the byte order of the data. Do not change it. The module version is also listed in the CHANGELOG.md file shipped with the module.

5. Migration

Robot module 1.5 is required to receive the new data of LS 1.5 (mainly the neural network label nn_label). Info data is now stored by key, so the order of the values in the response no longer matters. Robot programs that only read the variables listed in section 2.4 do not need changes. Update pho_common.src and pho_common.dat (and pho_loc_client.xml if needed) and keep your own programs.

New in 1.5: nn_label variable, example programs comm_check.src and reuse_scan.src.

See Migration from LS 1.4.x to LS 1.5.x for details.